The Logical Protocol Unit: towards an Optimal Communication Protocol

The performance of large software systems based on a server-slave architecture depends heavily on the design of the interprocess communication (IPC) protocol. In this paper different approaches of the logical structure of the protocol of the IPC communication are proposed and analyzed. The term of a logical protocol unit (LPU) is defined. All basic actions of the software system are logically grouped into units and transferred jointly via the interprocess communication facilities of the underlying operating system. An algorithm is given for the calculation of specific LPUs. It is shown that the total performance of the whole system is affected dramatically by different logical protocol structures; increased by larger logical protocol units and decreased by smaller one. This result is applicable to all types of IPC based systems, as beneath all large industrial applications. It was tested and analyzed with an existing relational data base system. Processes and communication Large software applications in the industry consist mainly of several processes, which run timesliced (virtually parallel) on a hardware system and communicate via the interprocess facilities [Roch85] of the underlying operating system. This design is demanded by the conventional server-slave architecture of centralized software systems. The slave processes are applications which represent the interface to users or other programs. In the following these programs are called ́user processes ́. The central server keeps up the connection with the user processes and is actually performing the work of the system (e.g. database access, system control, ...). Therefore a very time consuming part of the server task is the exchanging of information with the user processes. To partition a large program into smaller processes has the advantage of smaller program sizes (smaller main memory requirements), higher performance by workload sharing, logical structuring of tasks, etc.. It is obvious that the efficiency and the usage of the interprocess facilities is of heavy importance for the performance of the whole system. The efficiency is dependent on the operating system but 1 Authors permanent address: Erich Schikuta, Institute of Applied Computer Science, Dept. of Data Engineering, University of Vienna, Rathausstr. 19/4, A-1010, Vienna, Austria the way of the usage of the IPC facilities is defined by the software system (and therefore tunable). The logical protocol unit For the following discussion of the problem the term of a logical protocol unit (LPU) is defined. This is a collection of information (operations and data) transferred jointly by the IPC facilities. It can be seen as an atomic transaction changing the state of the system from one synchronized situation to another. Synchronized means that the communicating processes can react to arising exception situations of the system sensibly. Atomicity Atomicity in our sense of protocol units is similar to the definition of an atomic action used in the area of transaction processing in database systems. It is a sequence of actions which either are performed in entirety or are not performed at all ([Ceri84]). An action in the context of transaction processing is basically a read or write action of the database system ([Voss91]). An action in our terminology can be any information transferred between processes. Trigger and information actions We distinguish between trigger and information actions. A trigger action forces the system to transfer the state of the system to a new state. An information action delivers the data necessary for the transition between states. Informally we can speak of operations and data. An example is the insertion of an employee data record into a database system2. The system consists of a number of user processes, which provide the user interface, and a centralized database server. The insertion transaction consists of the information action, which is the transport of the employees information, as employee-number, name, department-number, etc., and the trigger action, which executes the insertion of the record. The situation is different to the conventional database transaction, where normally more than one action (usually the number of actions stored in the transaction table) has to be rolled back to react to an exception. This 'reaction' is generally a recovery, which can be triggered by a user request or is automatically triggered by a special system state, like a system crash. The length of a transaction atom is defined by the placement of a BOT (begin of transaction) and an EOT (end of transaction). This information is provided by the user program. For an LPU this situation is not comprehensive enough, because with a protocol unit nothing is said about the actual length of the unit sequence, i.e. the number of actions. The maximal number of actions an LPU is restricted by the constraint that the system can react to any exception situation with a a single (and obviously final) recovery action. On the other hand the system has not to rollback a number of LPUs to reach a consistent state of the system again. 2 Generally we use database system transactions as examples, which corresponds to the succeeding heuristic analysis.